IBIS Macromodel Task Group Meeting date: 04 October 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta * Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki * Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Curtis to send out revised minutes from the September 20th meeting. - Done. - Bob Ross to send out a BIRD 147.2 proposal containing the changes discussed. - Done. - Arpad to send an email to the Open Forum with ATM's recommendation to reject BIRD 128.2. - Done. - Michael Mirmak to draft a clarification BIRD for AMI Output parameters. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Minutes from the September 27th meeting had not yet been posted for review. ------------- New Discussion: - Arpad: I left the agenda the same as last week. - I'm not sure if we have updates on any of our topics. - Bob Ross did produce a draft of BIRD 147.2 and email it out. - Bob R.: [sharing draft 3 of BIRD 147.2] - BCI_Protocol rule: "BCI_Protocol must be present if the model supports any BCI protocol." - I moved this to the Usage Notes: section. - Following Mike LaBonte's suggestion, we explicitly state that parameters track BCI_Protocol. - For example: "BCI_ID must be present if BCI_Protocol is present. BCI_ID must be absent if BCI_Protocol is absent." - I moved these rules to the Usage Notes: sections. - In table YY1: - For the parameters secondary to BCI_Protocol, under requirements: "No, Yes if BCI_Protocol is present." - Bob M.: BCI_GetWave_Block_UI is optional if BCI_Protocol is present. - For the other secondary parameters, we now state that they must be absent if BCI_Protocol is absent. - Should we make that same statement for BCI_GetWave_Block_UI? - Bob R.: Yes, I understand, it is optional, but illegal without BCI_Protocol. - Bob M.: Yes, there's no practical use for BCI_GetWave_Block_UI if BCI_Protocol is absent. - Bob R.: Okay, I can add that. - Arpad: I understand that for clutter purposes it's advisable not have the secondary parameters there without BCI_Protocol. But, is it going to hurt anything if they're there? Is it worth the trouble to explicitly prohibit them if BCI_Protocol isn't there? - Bob M.: I was just thinking of someone's comment that for the purposes of the parser it's more convenient to explicitly disallow it. - Curtis: I think it's worth the trouble to explicitly disallow it. We might as well spell it out like the other three secondary parameters. There's no good reason for it to be there without BCI_Protocol. - Arpad: Okay, if it's easier to explicitly disallow it that's fine. I was thinking it might be more work that way. - Bob R.: Should we just make it a clean sweep and make it required if BCI_Protocol exists, and illegal if BCI_Protocol doesn't exist (like the other 3)? Or, should we leave it as it currently is, optional if BCI_Protocol exists, and simply add that it is illegal if BCI_Protocol doesn't exist. - Radek: The latter sounds okay. We can keep it optional. - Bob R.: I will email a draft 4 of BIRD 147.2. Bob Ross and Radek's discussion of Editorial Task Group Issues: - Bob Ross: We met yesterday [Monday, October 3, 2016]. - I can summarize. - We looked at ECL, PECL, split PECL with respect to reference. - Radek proposed a [GND Reference] keyword, which could be called a [Local Reference]. - If this keyword is missing, the local reference is assumed to be 0.0V. - If the value of [GND Reference] is non-zero, then all of the voltages embedded in the IBIS model (with some exceptions) are now relative to this local reference. - All the v(t) tables, for example, get shifted. - The Vinl, Vinh, thresholds get shifted. - All the relevant [Model Spec] voltages get shifted. - With respect to PECL, or ECL, all of the examples were the most positive rail. - For ECL, that's usually ground. - For PECL, that might be 5V. - If you put 5.0 in the new keyword for your PECL model, then for the rest of your model you would basically reproduce the ECL tables. - We still have to discuss things further. - If that [GND Reference] happens to have the same value as one of the existing [* Reference] keywords, then the corresponding rails are considered the same (shorted). - C_comp now gets connected to the [Local Reference]. - [Package Model] reference is the [Local Reference]. - Exceptions are: - This is a new keyword within a [Model], so whatever is defined within the [Model] as a reference voltage is still with respect to 0.0. - The I/V tables don't shift. They're always relative to their [* Reference] voltages, so they don't shift around. - Anything that's differential does not shift. - Radek and I haven't yet discussed an RS232 model that I sent him. - We also discussed the [Pin Reference] keyword. - Radek: The discussed examples show a likely assignment by the model maker. - We are not imposing this on the model maker. - We are giving them a way to clearly specify something they currently can't. - This [GND Reference] in a way is an alternative to the [DUT Reference] that we discussed earlier. It is probably slightly more flexible and general than [DUT Reference] was. - We still have to discuss any interrelationship between [Pin Reference] and [GND Reference]. - Bob R.: We considered the case of a common mode voltage for a differential application, where we might want C_comp to go to that common mode voltage, which isn't currently defined anywhere. Maybe we don't want to support this. - Walter's hypothetical scenarios were discussed. - Some with the reference in the [Model]. - Some with the reference Pin defined in the [Component]. - General answer is, "it depends on how the model was extracted." - Radek: Once we finalize it we can broadcast it. - Bob's summary notes show the outcome of some of the discussions, but not the details and all the cases that were discussed. - Bob: We are going to meet further, perhaps Friday. - If we do introduce [Local Reference] in a manner that affects all voltages, the impact to the parser is that we have to identify every affected voltage. The parser would then shift the model values according to the value of [Local Reference], so it's as though it were a current model relative to 0.0, and then check the model with the existing parser code. - There could be major implications since the parser and EDA tools still have to support existing models as is. - We haven't fully examined this change from a parser or specification language perspective. - It could require the addition of multiple statements throughout the document saying that everything is relative to the optional [Local Reference]. - Arpad: Does this discussion cover all the subtopics under this item on the agenda? There are four subtopics 7a through 7d. - Radek: 7b we have addressed. We said we prefer "model in simulation" to DIA (device in action). - 7a and 7c are covered in this discussion. - We noted that any two [* Reference] entries for which all 3 corner case values are identical will be considered to have their corresponding terminals the same (shorted). That will clarify a number of things, including which *_ref serves the reference. We won't have to speculate anymore, it will be specified by the model maker. - 7d. At the moment there is the implication of this [Local Reference] on the [Receiver threshold] values. We still have to talk about [External Reference], but that is not yet part of the discussion. - Bob: As a reference, it could be the same as the [External Reference]. - However, that's not a valuable reference for output buffers because [External Reference] was intended as a measurement reference for certain types of buffers, DDR buffers in particular. It was intended as a reference voltage that was not necessarily one of the rails. - We can decide whether to allow it all or simply not recommend it. - We sort of agree that we don't want to allow it. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Bob Ross to send out a BIRD 147.2 proposal containing the changes discussed. ------------- Next meeting: 11 October 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives